- Use main's new worker_managers/ docs structure (PR finos#611)
- Move worker_manager_adapter/orb.rst to worker_managers/orb.rst
- Add ORB entry to worker_managers/index.rst
- Accept deletion of reorganized files (examples.rst, worker_manager_adapter/index.rst, common_parameters.rst)

- Register ORBWorkerAdapterConfig with _tag = "orb" for discriminator-based
  TOML parsing in the scaler all-in-one launcher
- Add orb subcommand to scaler_worker_manager dispatcher
- Add ORBWorkerAdapterConfig to WorkerManagerUnion in scaler.py
- Remove redundant top-level event_loop and worker_io_threads fields from
  ORBWorkerAdapterConfig in favour of the existing worker_config equivalents
- Update docs (commands.rst, orb.rst) and README to reflect the unified entry point
- Add tests for orb subcommand parsing, TOML config, and _run_worker_manager dispatch

The orb worker manager is now accessible via the unified
scaler_worker_manager orb subcommand, making the dedicated
entry point redundant.

When ORBClient is initialised with app_config=, its _ensure_raw_config()
merges only default_config.json (which has provider_defaults: {}) with the
caller-supplied dict, skipping the _load_strategy_defaults() call that
normally loads aws_defaults.json.  As a result get_effective_handlers()
returns {} and RunInstances is absent from supported_apis, causing:

  ApplicationError: Provider does not support API 'RunInstances'. Supported APIs: []

Fix by including provider_defaults.aws.handlers explicitly in
_build_app_config() so the RunInstances handler definition is always
present regardless of how ORB loads its config.

When the ORB adapter is at capacity it returns TooManyWorkers, but the
scheduler's worker count (based on received heartbeats) may still be
below max_task_concurrency because newly-created instances haven't sent
their first heartbeat yet. This caused the scheduler to re-request a
worker on every heartbeat, spamming the log.

Fix: track sources that have returned TooManyWorkers and suppress new
StartWorkers requests for that source until the scheduler's own worker
count drops below max_task_concurrency (indicating a worker left and
the ORB adapter has freed up capacity).

Also fix a latent bug in all three scaling policies where the capacity
check `len(managed) >= max_task_concurrency` is always True when
max_task_concurrency == -1 (unlimited), blocking all scaling.

The module-level `from orb import ORBClient as orb` caused CI tests to
fail when patching ORBWorkerAdapter, because importing the module
triggered the import of `orb` which is not installed in CI. Moving the
import inside `_run()` defers it until the adapter is actually used.

Replace the deprecated scaler_cluster command with scaler_worker_manager
baremetal_native, passing --mode fixed and --worker-manager-id sourced
from ec2-metadata.

Fix incorrect version.txt path in build.sh (was two levels up, should be three), and add the newly built AMI ami-0b76605999d8f5d2b for scaler 1.26.4 / Python 3.13 to the ORB docs table.

DEFAULT_MAX_TASK_CONCURRENCY was cpu_count() - 1, which evaluates to 0
on single-core machines. Remove the subtraction so at least one worker
is started by default.

The _at_capacity_sources clearing condition was inverted: it cleared
suppression when managed_worker_ids < max_task_concurrency, which is
exactly the case during EC2 boot (0 workers, instance not yet registered).
This caused the scheduler to resume spamming StartWorkers on the very
next heartbeat after receiving TooManyWorkers.

Replace the Set-based approach with a baseline Dict that records the
managed worker count at the time TooManyWorkers was received. Suppression
is now held until the scheduler's view of workers grows beyond that
baseline, i.e. at least one booting instance has sent its first heartbeat.